Infer the PR from the checkout, and render the queue as one status line - #46
Conversation
Two things an agent had to work around by hand. A bare `crq next` inside a checkout now infers its target: read the branch, match a remote to a repository slug, and ask GitHub which open pull request has that head. The skill has told agents to run crq from inside the checkout since `local_work` landed; now that being there is worth something, they no longer have to paste a repo and a number they already stand in. And `crq status --line` renders the queue as a single line for a status bar, so "still going?" has an answer that costs no turn. It reports only what crq can know: stranded outranks blocked outranks reviewing, and `next #N` appears only when the queue actually knows who is next. `crq status` now rejects a positional argument instead of ignoring it — `crq status 41` looked like it reported on that PR.
|
Warning Review limit reached
Next review available in: 13 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
|
@codex review |
✅ Action performedReview finished.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad7a9b2d58
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Four review findings on this branch, all correct. Inference reached only next and wait, while the PR claimed every command that takes a target. feedback, loop, cancel and debug enqueue now route through the same helper, so a bare call works wherever a target is taken. Fork checkouts could not be inferred at all. Taking the first remote and its own owner asks /repos/me/app/pulls?head=me:branch, but the pull request is filed against upstream — so the one case where carrying the arguments by hand is most annoying reported that no PR exists. Inference now considers every GitHub remote as a base and every remote owner as a head. A single-remote checkout still costs exactly one request. That makes a remote slug an API lookup rather than a comparison, so it now requires a GitHub remote: repoSlugFromRemote is deliberately loose for matching, where a wrong guess merely fails to match, and would have turned /home/me/code/app into a request for code/app. The status line could say "blocked" and then name the next PR in the same breath — but a quota-free round stays actionable precisely because the account window has no authority over it. Ready work now outranks the block. It could also point past a stranded reservation, which reads as though the queue is moving; the earlier precedence test only proved that case with an empty queue behind it.
|
@codex review |
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5a3697b629
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| default: | ||
| parts = append(parts, "🟢 ready") |
There was a problem hiding this comment.
When the front round is awaiting a future RetryAt or the minimum-fire interval, Queue is nonempty but sets ReadyAt/Why, making ready false. If there is no account block or in-flight round, this default still renders crq 🟢 ready · 1 queued, even though nothing can fire yet. Add a separate non-ready queued state, ideally showing the applicable wait or countdown.
Useful? React with 👍 / 👎.
| // against a repo crq already knows, where a wrong guess simply fails to | ||
| // match. Here the slug becomes an API lookup, so a local path like | ||
| // /home/me/code/app must not turn into a request for code/app. | ||
| if !strings.Contains(strings.ToLower(fields[1]), "github.com") { |
There was a problem hiding this comment.
When a non-GitHub remote merely contains github.com in its path—for example /home/me/src/github.com/owner/repo.git or https://gitlab.example/github.com/owner/repo.git—this substring check accepts it and repoSlugFromRemote turns it into owner/repo. If that GitHub repository has an open PR for the same branch, a bare command can silently operate on the wrong PR. Parse and validate the actual host while preserving deliberately supported SSH host aliases.
Useful? React with 👍 / 👎.
| if err != nil { | ||
| return "", 0, err | ||
| } |
There was a problem hiding this comment.
When a checkout has a stale, deleted, or inaccessible secondary GitHub remote, its ListPulls lookup returns 404 and this immediately aborts inference—even if an earlier valid remote already produced the unique PR match. Since the Cartesian search treats every remote as only a candidate, a not-found candidate should be skipped while authentication, throttling, and other request failures should still be returned.
Useful? React with 👍 / 👎.
| crq next [<repo> <pr>] [--wait] emit the single next action as JSON (--wait blocks) | ||
| omit the target inside a checkout: crq reads the | ||
| remote and branch to find the pull request |
There was a problem hiding this comment.
The runtime now accepts inferred targets, but the command-specific help for next, wait, loop, feedback, and cancel still prints mandatory <repo> <pr> forms, the general usage block still shows wait as mandatory, and the README command contract remains unchanged (including omitting status --line). This leaves the repository's designated contract and usage surfaces contradicting the new CLI, so update them alongside these new optional forms.
AGENTS.md reference: AGENTS.md:L5-L6
Useful? React with 👍 / 👎.
1 participant
Two ergonomics items from the v3 roadmap's P6, both about work an agent currently does by hand.
crq nextwith no argumentsA bare
crq nextinside a checkout infers its own target: read the current branch, match aconfigured remote to an
owner/nameslug, then ask GitHub which open pull request has that head(
head=owner:branch). If nothing matches, or more than one does, it says so rather than guessing.The skill has told agents to run crq from inside the checkout ever since
local_worklanded —local_workis only accurate there. This makes standing in the right place pay for itself instead ofstill requiring a repo and a number the agent is already inside of.
Applies to every command that takes a target, via one shared
target()helper.crq status --lineOne line, for a status bar:
It reports only what crq can actually know. Precedence is stranded > blocked > reviewing > idle, and
next #Nappears only when the queue genuinely knows who is next — the same restraint as thedashboard ordering: past the front, order is not knowable, because slot release comes from an
acknowledgement, not from pacing.
This is the countdown surface the roadmap moves heartbeats onto: a chat that wants to answer
"still going?" reads a line instead of spending a turn on
crq doctor.Also
crq statusnow rejects a positional argument.crq status 41previously ignored it and printedglobal status, which reads exactly like a report on PR 41.
Verification
gofmt -l .clean,go vet ./...clean,go test ./...green across all six packages.New tests pin the two things that would otherwise pass for the wrong reason:
headquery parameter. It previously returned every PR in therepository, so an inference asking for the wrong branch would still have satisfied a
single-result assertion.
TestStatusLineasserts the output contains no newline (it renders into a bar) and that astranded round excludes every lower-priority status, not merely that "stranded" appears.
Ref #42